Session on April 27th, 2017, for UPF Students.

By Xavier de Pedro, Ph.D. 1/11 project admin (xavi at tiki.org).

Slides: Slideshow | Short Link: http://seeds4c.org/170427TikiUPF

Derived from several sources (see References below)

Outline

1. FLOSS (Free/Libre Open Source Software): https://sf.net/projects/tikiwiki/
2. Community: https://tiki.org/Community
3. Association: https://tiki.org/TSCA

See also: https://tiki.org/History

• No hunting around to find the best 3rd party module
• No needing to re-install 3rd party modules at every upgrade, hoping they all still work!
• Because, in Tiki, everything is built-in and developers collaborate on and extend features, instead of just cooperating around a core (when they are not just outright competing...). And upgrades are easy!
• Do you have two wiki pages for the same thing? No. Why would it be so for features?
• More later about the model, let's describe some features!

• Users can be in any number of groups
• Groups can be included in groups
• Registration system
• Over 200 permissions, which can be:
  • System-wide (global)
  • by item (object)
  • by category (workspaces)

• Powerful wiki syntax
• Powerful version history and diff engine
• Book and table of content
• Email notification of changes
• Advanced plugins
• Advanced translation synchronization

• Create custom application
• Bug tracker, application forms, contact forms, etc.
• Can create reports in wiki pages
• Multilingual
• Can link to other trackers
• 20+ field types
  • text field, text area, checkbox, numeric field, drop down, radio buttons, user selector, date and time, image, category, email, auto-increment, Maps, computed field, attachment, etc.

• Several calendars
• iCal
• Recurring events
• RSS feeds
• Distinct permissions

• Several blogs
• Topics
• Tags & categories
• RSS feeds
• Permissions
• Can use wiki syntax

• Formulas
• Charts
• Version history
• Can use wiki syntax in calls
• Can embed sheets & charts anywhere in Tiki

• You are currently watching it!
• Made from wiki pages
• Slide notes, for a second screen
• Timer
• Uses S5 standard

• Threaded or flat forums
• Mailing list integration
• Can use wiki syntax
• File Attachment
• Email notification of replies

• Hierarchical galleries
• Check-in/Check-out/lock
• Categories for files
• Permissions
• Watch (notification of change by email)
• WebDAV support

• Vector drawing
• Shapes & lines
• Stored in SVG
• Integrates SVG-edit (JavaScript)
• Layers

• Select screen area
• Capture screenshot as PNG, JPG, etc.
• Record video
  • Audio from microphone
  • Pause during the recording
  • Play before upload
  • Post-recording editor to remove frames
  • Pick splash frame
  • Generates a .swf file
• Integrates jCapture applet

• Translated to 40+ languages
• Wiki has awesome i18n change tracking
• Wiki-translation.com

See https://doc.tiki.org/PluginPivotTable

Remember: https://doc.tiki.org/Features (rated with self-critricism)

Example: PluginTrackerList vs PluginList

• Wiki community
  • Do-ocracy, P2P
• Wiki way participation to the code
• All-in-one codebase
  • Inherent synchronized releases
• Lots of features, but no duplication
  • Do you have two wiki pages for the same thing? No. So, why would it be so for features?
• Dogfood
  • *.tiki.org sites are upgraded before a .0 is released
• Scheduled releases (twice per year)
  • Long Term Support (LTS) every third release, with 5 year support
• Commercial eco-system based on services, not code.
  • All code is shared

Offers benefits

• Tons of features, without duplication, excellent code re-use and code review, more collaboration, tight integration, easy upgrades, excellent interaction between features, etc.
• Permits huge changes between versions because we don’t have to worry about breaking 3rd party extensions.
• Less code for the community to maintain: http://en.wikipedia.org/wiki/Technical_debt
• No abandoned module, because a new shiny one just came out
• No dependency hell (needing to re-install 3rd party modules at every upgrade, hoping they all still work!)
• No hunting around to find the best 3rd party module

But does bring challenges

• Huge code base to maintain
• Admin panels with hundreds of features for a total of over 1200 settings/options! (we had to add a search!)
• Learning curve: 1200+ pages of documentation
• What should be sensible defaults?

Tiki 7.1 (as a reference) contained 11348 files and it's the FLOSS Web application with the most built-in features. About half the code in Tiki is maintained by the Tiki community and the other half is re-using code from external libraries like Smarty, Zend Framework, jQuery, etc.

So say we maintain about 6000 files. Sounds like quite a bit, but let's put this into perspective:

• Joomla! has 9463 "extensions"
• Drupal has 15948 "modules"
• WordPress has 19382 "plugins"

Tiki covers the vast majority of features that these 3 systems offer via the thousands of extensions. So just about any project you could do with Joomla!, WordPress or Drupal, you could also do it with Tiki. Yet, they have more extensions to maintain than we have files! (and since they can't possibly maintain them all, it leads to dead-end extensions and disappointed end-users).

See: https://tiki.org/Coping+with+Complexity
http://en.wikipedia.org/wiki/Technical_debt

Instead of having thousands of extensions, we collaborate on the code base, and can make very specific apps thanks to profiles.

• Value of a free source project
  • Beyond code: the community and the experience
  • Combining the different features, producing new benefits never imagined by the authors
  • How to share this knowledge?
• Profiles to configure your Tiki
  • On wiki pages (collaborative, version history, etc.)
  • Can be used not just at install, but at any time and can be combined
  • Not just for settings, but also for data
  • Since there is no extra code, can be designed for very specific, long tail uses

We can have hundreds of profiles for an out-of-the-box experience, with a single code-base!

"Not Invented Here (NIH) is a term used to describe persistent social, corporate or institutional culture that avoids using or buying already existing products, research or knowledge because of their external origins. It is normally used in a pejorative sense, and may be considered an anti-pattern." Source: Wikipedia

Half of the code in Tiki comes from other projects! Tiki includes code from over 60 external libraries, including:

• BigBlueButton Web conferencing
• OPcache, XCache, Memcached and APC
• R (statistics & maths for any science)
• GD & ImageMagick
• Zotero (references)
• OpenLayers (OpenStreetMaps, MapServer and GoogleMaps)
• Cclite (community currency)
• PayPal
• Various authentication (phpBB, LDAP, Shibboleth, CAS, OpenID, etc.)
• Subversion
• Kaltura video platform
• 40+ examples at https://doc.tiki.org/Interoperability

• $20 million according to the Basic COCOMO model
  • https://www.openhub.net/p/tikiwiki/estimated_cost
  • "Beyond just development time, COCOMO is meant to include the design, specification drafting, reviewing and management overhead that goes along with producing quality software."

• Yet, the Tiki Software Community Association (TSCA) has no employees
• Tiki doesn't depend on any funding from any company, foundation, government or anyone. It thrives thanks to the community.

"show.tiki.org project: improve bug reporting and solving", by Jean-Marc Libs. FOSDEM 2014.

See also:

• How to add a Wish
• Tiki_Presentation_Fosdem_2014_v5_publish.pdf

• "Hello World" for new Devs: https://dev.tiki.org/Hello+World
• How to get Commit Access: https://dev.tiki.org/Commit
• Where to report bugs/wishes: https://dev.tiki.org/Make+a+wish
• Where to send questions: https://tiki.org/forums -> Mailman lists: users & devel
• Tiki (Coding) Fests: https://tiki.org/TikiFest

The most comprehensive and integrated Free / Libre / Open Source enterprise software suite ever developed

WikiSuite™ is especially suited to knowledge-centric organizations and offers most (80%+) of the data and information management features all organizations need

• So things are good, why change?

We need friendly software on the server and on the client computer and mobile device to avoid dealing with so many permutations and be able to develop advanced features and tight integration. Ex.: We have a Tiki chat feature, but we can't do presence.

• Best of breed vs. suites vs. feature bloat
• While Ted Nelson coined "Intertwingularity" to express the "complexity of interrelations in human knowledge", it's the same problem for software. There will always be overlap.
• Apple controls both the hardware and the software which make it much simpler (drivers, UI, etc.)
• Every app claims interoperability (ex.: via open standards)
  • It's very hard! Even within apps of a same publisher!
• Because of Zawinksi's law ("Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." ), intertwingularity and the progressive move to Web Applications, more & more apps and SaaS will offer "everything".
• "It's best to do one thing really, really well." –Google
  • Google started just with search. And now?

• The Tiki model:
  https://tiki.org/model
• A Process That Is Not, IEEE Software, November/December 2009 (vol. 26 no. 6), ISSN: 0740-7459 by Hakan Erdogmus
  https://tiki.org/tiki-download_wiki_attachment.php?attId=809&page=Model&download=y
• Wikisuite
  http://wikisuite.org
• "Going beyond Tiki Wiki CMS Groupware. Server, Web, Desktop and Mobile suite". By Marc Laporte. 2015.
  https://tiki.org/Presentation-Tiki-Suite-ADTE-2015
• Tiki for dummies Smarties at VHIR. By Xavier de Pedro. 2012.
  http://ueb.vhir.org/show:2012-05-04+Xavier+de+Pedro+Tiki+Seminar

Alias links for this page:
170427TikiUOC | 170427TikiUPF | 170427 Tiki Dev for UOC Master on FLOSS